Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Right to left mode #611

Merged
merged 3 commits into from
Nov 20, 2024
Merged

Right to left mode #611

merged 3 commits into from
Nov 20, 2024

Conversation

chiragchhatrala
Copy link
Collaborator

@chiragchhatrala chiragchhatrala commented Nov 8, 2024

Summary by CodeRabbit

Release Notes

  • New Features

    • Introduced a toggle switch for enabling right-to-left layout in the form customization interface.
    • Added support for right-to-left layout in forms, enhancing accessibility for users with right-to-left language preferences.
  • Improvements

    • Enhanced form handling and error management in various components to better support the new layout features.
    • Updated styling and layout logic to dynamically adjust based on the layout_rtl property.
    • Improved loading logic and error handling for forms, ensuring a smoother user experience.

These changes improve user experience by providing flexible layout options for diverse language needs.

Copy link
Contributor

coderabbitai bot commented Nov 8, 2024

Walkthrough

The pull request introduces a new boolean validation rule for the layout_rtl field in the UserFormRequest. It adds the layout_rtl property to the FormResource, modifies the Form model to allow mass assignment of this property, and includes a migration to add the corresponding column to the database. Additionally, client-side components are updated to support right-to-left layout configurations, including new toggle switches and style bindings in various Vue files. These changes collectively enhance the form handling capabilities for right-to-left languages.

Changes

File Change Summary
api/app/Http/Requests/UserFormRequest.php Added validation rule: 'layout_rtl' => 'boolean' in rules() method.
api/app/Http/Resources/FormResource.php Added property: private array $cleanings; updated getCleanigns and getProtectedForm methods to include layout_rtl.
api/app/Models/Forms/Form.php Added layout_rtl to $fillable array for mass assignment.
api/database/migrations/2024_11_08_091638_add_layout_rtl_to_forms_table.php Added layout_rtl column as boolean with default value false.
client/components/open/forms/OpenCompleteForm.vue Added conditional styling for direction based on form.layout_rtl; refined error handling in submitForm.
client/components/open/forms/components/form-components/FormCustomization.vue Added toggle switch for layout_rtl in form customization.
client/components/open/forms/components/form-components/FormEditorPreview.vue Added style binding for logo container based on form.layout_rtl.
client/composables/forms/initForm.js Added layout_rtl property with default value false in initForm return object.
client/pages/forms/[slug]/index.vue Updated logo styling and refined loadForm function to include new parameter and improved error handling.

Possibly related PRs

  • fix closed form #583: The changes in OpenCompleteForm.vue involve modifications to the rendering logic and structure, which may relate to the new layout_rtl field added in the main PR, as both involve form layout handling.
  • apply first submission modal changes #584: The changes in OpenCompleteForm.vue include logic that checks for the first submission and form ownership, which could be relevant to the overall form handling and layout management introduced in the main PR.

Poem

🐰 In the land of forms, where layouts play,
A toggle for RTL has come to stay.
With styles that shift, and errors that mend,
Our forms now embrace, on this we depend!
So hop with delight, for changes are here,
Right-to-left magic, let's all give a cheer! 🎉


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (9)
client/composables/forms/initForm.js (1)

Line range hint 89-116: Add layout_rtl to default values.

The setFormDefaults function should include the new layout_rtl property to maintain consistency with the initialization defaults.

Apply this diff:

   const defaultValues = {
     title: 'Untitled Form',
     visibility: 'public',
     theme: 'default',
     width: 'centered',
     size: 'md',
     border_radius: 'small',
     dark_mode: 'light',
     color: '#3B82F6',
     hide_title: false,
     uppercase_labels: false,
     no_branding: false,
     transparent_background: false,
     submit_button_text: 'Submit',
     confetti_on_submission: false,
     show_progress_bar: false,
     bypass_success_page: false,
     can_be_indexed: true,
     use_captcha: false,
+    layout_rtl: false,
     properties: [],
   }
api/app/Http/Resources/FormResource.php (2)

Line range hint 11-11: Add PHPDoc for the cleanings property.

Consider adding documentation to explain the purpose and expected structure of the cleanings array.

+    /**
+     * Array of cleaning operations for the form.
+     *
+     * @var array
+     */
     private array $cleanings = [];

77-77: Consider grouping related layout properties together.

For better code organization, consider grouping the layout_rtl field with other layout-related properties like width and theme.

             'theme' => $this->theme,
             'width' => 'centered',
+            'layout_rtl' => $this->layout_rtl,
             'is_password_protected' => true,
             'has_password' => $this->has_password,
-            'layout_rtl' => $this->layout_rtl,
             'no_branding' => $this->no_branding,
api/app/Http/Requests/UserFormRequest.php (2)

36-36: Consider enhancing the layout_rtl validation rule.

While the boolean validation is appropriate, consider these improvements to maintain consistency with other UI-related fields:

  1. Add the 'required' rule like other UI customization fields
  2. Use Rule::in([true, false]) for stricter validation
  3. Add a PHPDoc comment describing the field's purpose
-            'layout_rtl' => 'boolean',
+            // Controls the form's text direction (right-to-left mode)
+            'layout_rtl' => ['required', 'boolean', Rule::in([true, false])],

Line range hint 10-13: Consider updating class documentation.

The class documentation could be enhanced to mention the RTL layout support as part of the form customization features.

 /**
  * Abstract class to validate create/update forms
+ * Supports form customization including themes, layouts (including RTL), and styling
  *
  * Class UserFormRequest
  */
client/components/open/forms/components/form-components/FormCustomization.vue (1)

116-123: Implementation looks good, with some UX enhancement opportunities.

The RTL toggle switch implementation is clean and follows the established patterns. The placement in the Layout & Sizing section is appropriate, and the help text is clear.

Consider these UX enhancements:

  1. Add a visual indicator (like ←/→) to help users quickly identify the current text direction
  2. Consider previewing the RTL layout change in real-time within the form editor

Example enhancement:

     <ToggleSwitchInput
       name="layout_rtl"
       :form="form"
       class="mt-4"
-      label="Right-to-Left Layout"
+      label="Right-to-Left Layout (←)"
       help="Adjusts form layout for right-to-left languages."
+      @update:model-value="previewRTLLayout"
     />
client/pages/forms/[slug]/index.vue (1)

23-23: LGTM! Consider extracting the RTL direction logic to a computed property.

The RTL style binding is correctly implemented. However, since this RTL logic might be reused elsewhere in the component, consider extracting it to a computed property for better maintainability and reusability.

+ const getDirection = computed(() => form.value?.layout_rtl ? 'rtl' : 'ltr')
- :style="{ 'direction': form?.layout_rtl ? 'rtl' : 'ltr' }"
+ :style="{ direction: getDirection }"
client/components/open/forms/OpenCompleteForm.vue (2)

5-5: Simplify the RTL direction binding.

The optional chaining operator (?.) is redundant since the parent div already has v-if="form". Consider simplifying and adding a default value:

-    :style="{ '--font-family': form.font_family, 'direction': form?.layout_rtl ? 'rtl' : 'ltr' }"
+    :style="{ '--font-family': form.font_family, 'direction': form.layout_rtl || false ? 'rtl' : 'ltr' }"

Line range hint 1-400: Consider comprehensive RTL testing and accessibility.

The RTL implementation looks good, but please ensure:

  1. Testing with various RTL languages (Arabic, Hebrew, Persian, etc.)
  2. Verification of form elements alignment in RTL mode
  3. Testing with screen readers and RTL text-to-speech
  4. Validation of bidirectional text rendering

Consider adding RTL-specific test cases to your end-to-end testing suite.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between ef12c82 and fed3054.

📒 Files selected for processing (9)
  • api/app/Http/Requests/UserFormRequest.php (1 hunks)
  • api/app/Http/Resources/FormResource.php (1 hunks)
  • api/app/Models/Forms/Form.php (1 hunks)
  • api/database/migrations/2024_11_08_091638_add_layout_rtl_to_forms_table.php (1 hunks)
  • client/components/open/forms/OpenCompleteForm.vue (2 hunks)
  • client/components/open/forms/components/form-components/FormCustomization.vue (1 hunks)
  • client/components/open/forms/components/form-components/FormEditorPreview.vue (1 hunks)
  • client/composables/forms/initForm.js (1 hunks)
  • client/pages/forms/[slug]/index.vue (1 hunks)
🔇 Additional comments (12)
api/database/migrations/2024_11_08_091638_add_layout_rtl_to_forms_table.php (4)

1-6: LGTM! File structure and imports are correct.

The necessary Laravel migration classes are properly imported.


7-7: LGTM! Migration class is properly defined.

The anonymous class extending Migration follows Laravel's recommended structure.


21-26: LGTM! Rollback functionality is properly implemented.

The down method correctly drops the layout_rtl column, providing a clean rollback path.


11-16: Consider performance implications of the new column.

The implementation is correct, but consider these architectural points:

  1. If this column will be frequently queried (e.g., filtering forms by RTL mode), consider adding an index.
  2. Since this is a boolean column with a default value, ensure that any existing queries in the codebase properly handle this new column.

Let's check for existing queries that might be affected:

✅ Verification successful

No performance concerns with the new layout_rtl boolean column

Based on the codebase analysis:

  1. The layout_rtl column is a simple boolean with a default value, similar to other boolean flags in the forms table like no_branding, hide_title, etc.
  2. There are no existing queries that filter or sort by boolean columns in the forms table, suggesting this column won't impact query performance.
  3. The Form model and controllers don't show any complex querying patterns that would require indexing of boolean columns.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for existing form queries that might need updating
rg -l "select.*from\s+forms" --type php

Length of output: 41


Script:

#!/bin/bash
# Let's try a more comprehensive search for form queries using different patterns
rg -l "forms.*where|from\s+forms|join\s+forms" --type php

# Also search for Eloquent query usage
rg -l "Form::where|Form::select|Form::find" --type php

# Check for model definition to understand query patterns
fd Form.php

# Look for repository or service classes that might handle form queries
fd -e php -E "migrations" | grep -i "form"

Length of output: 5683


Script:

#!/bin/bash
# Let's examine the Form model and any existing queries that might need to consider the new column
cat api/app/Models/Forms/Form.php

# Check form-related controllers for query patterns
cat api/app/Http/Controllers/Forms/FormController.php

# Look for any existing boolean column filtering in forms
rg "where\(['\"]forms['\"].*true|false" --type php

Length of output: 45248

client/composables/forms/initForm.js (2)

16-16: LGTM: RTL property addition looks good.

The layout_rtl property is appropriately placed in the customization section with other layout-related properties.


Line range hint 1-116: Verify RTL implementation across components.

The changes look good, but let's verify the RTL implementation in related components mentioned in the summary.

✅ Verification successful

Let me try a different search strategy to locate the relevant files and RTL implementation.


Let me search specifically in the identified form components for RTL implementation.


RTL implementation is properly integrated across components

The RTL implementation is correctly handled across the form components:

  • FormCustomization.vue has the RTL toggle control with layout_rtl binding
  • FormEditorPreview.vue properly applies RTL direction using conditional styling
  • The layout_rtl property in initForm.js is appropriately consumed by these components
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify RTL implementation in related Vue components
# Expected: Find RTL-related bindings and logic in the components

echo "Checking OpenCompleteForm.vue for RTL text direction..."
rg -A 3 "layout_rtl" "client/components/forms/OpenCompleteForm.vue" || echo "File not found or no matches"

echo -e "\nChecking FormCustomization.vue for RTL toggle..."
rg -A 3 "layout_rtl" "client/components/forms/FormCustomization.vue" || echo "File not found or no matches"

echo -e "\nChecking FormEditorPreview.vue for RTL styles..."
rg -A 3 "layout_rtl" "client/components/forms/FormEditorPreview.vue" || echo "File not found or no matches"

Length of output: 1004


Script:

#!/bin/bash
# First, let's find all Vue files that might contain RTL-related code
echo "Finding Vue files with RTL-related code..."
rg -l "layout_rtl|direction.*rtl" --type vue

echo -e "\nChecking for RTL-related imports and usage..."
rg -A 3 "layout_rtl" --type vue

echo -e "\nFinding all form-related Vue components..."
fd ".vue$" --type f | grep -i "form"

Length of output: 6285


Script:

#!/bin/bash
# Search for RTL implementation in the identified form components
echo "Checking FormCustomization.vue for RTL implementation..."
rg -A 3 "layout_rtl|direction.*rtl" "client/components/open/forms/components/form-components/FormCustomization.vue"

echo -e "\nChecking FormEditorPreview.vue for RTL implementation..."
rg -A 3 "layout_rtl|direction.*rtl" "client/components/open/forms/components/form-components/FormEditorPreview.vue"

echo -e "\nChecking OpenForm.vue for RTL implementation..."
rg -A 3 "layout_rtl|direction.*rtl" "client/components/open/forms/OpenForm.vue"

echo -e "\nChecking VForm.vue for RTL implementation..."
rg -A 3 "layout_rtl|direction.*rtl" "client/components/forms/VForm.vue"

Length of output: 1089

api/app/Http/Resources/FormResource.php (1)

Line range hint 108-111: Fix typo in method name: getCleanignsgetCleanings

The method name contains a spelling error which should be corrected for better code maintainability.

-    private function getCleanigns()
+    private function getCleanings()
     {
         return $this->extra?->cleanings ?? $this->cleanings;
     }

Let's verify if this method is called elsewhere in the codebase:

✅ Verification successful

Fix typo in method name and its usage

  • api/app/Http/Resources/FormResource.php: Rename method from getCleanigns to getCleanings and update its invocation in the same file
-            'cleanings' => $this->getCleanigns(),
+            'cleanings' => $this->getCleanings(),

-    private function getCleanigns()
+    private function getCleanings()
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any references to the misspelled method
rg "getCleanigns"

Length of output: 183

client/components/open/forms/components/form-components/FormEditorPreview.vue (2)

80-80: Verify logo positioning in RTL mode.

The logo uses absolute positioning without explicit left/right properties. In RTL mode, this might cause unexpected positioning. Consider adding appropriate positioning classes that respect the RTL direction.

Let's check for any existing RTL-specific positioning classes:

#!/bin/bash
# Search for RTL-specific positioning in styles or classes
rg -t vue "right-\d+|left-\d+.*rtl" client/

Consider updating the class binding to handle RTL positioning:

-class="max-w-60 h-20 object-contain absolute transition-all"
+:class="[
+  'max-w-60 h-20 object-contain absolute transition-all',
+  form?.layout_rtl ? 'right-0' : 'left-0'
+]"

74-74: Consider implementing RTL support at a higher level.

While the RTL direction binding works, applying it only to the logo container might not provide complete RTL support. Consider moving this binding to a higher-level container to ensure consistent RTL behavior across all form elements.

Let's check if other components implement RTL at a higher level:

client/components/open/forms/components/form-components/FormCustomization.vue (1)

116-123: Verify RTL compatibility with auto-focus feature.

Since the form has an auto-focus feature (line 186), ensure that the focus handling works correctly in RTL mode, especially for the first input field on each page.

✅ Verification successful

Let me try searching without the file type filter since the Vue file type might not be recognized in the sandbox environment. This will help us find focus-related logic in the client directory.


Let's examine the actual focus-related code to understand how it's implemented and its interaction with RTL layout.


I want to see how the auto_focus setting is implemented in the actual form rendering and if there's any specific RTL-focus interaction logic.


I want to see how the first element focus is implemented and understand if there's any RTL-specific layout handling that might affect focus behavior.


Based on the gathered information, I can now provide the final response:

RTL layout implementation is CSS-based and independent of focus handling

The RTL layout is implemented through CSS direction property and doesn't interfere with the focus handling mechanism. The auto-focus feature is controlled by focusOnFirstFormElement() which is triggered independently of the RTL setting. Since:

  • RTL layout is applied via CSS direction: rtl property
  • Focus handling is managed separately through JavaScript
  • There's no direct interaction between RTL and focus mechanisms

The auto-focus feature should work correctly regardless of the RTL setting.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for focus-related logic that might need RTL consideration
rg -l 'focus|autofocus' --type vue

Length of output: 64


Script:

#!/bin/bash
# Search for focus-related logic with ripgrep, without file type filter
rg -l 'focus|autofocus' client/

Length of output: 984


Script:

#!/bin/bash
# Let's examine the focus-related code in FormCustomization.vue and related form components
rg 'focus|autofocus' -A 3 -B 3 client/components/open/forms/components/form-components/FormCustomization.vue

# Also check the form initialization logic
rg 'focus|autofocus' -A 3 -B 3 client/composables/forms/initForm.js

Length of output: 581


Script:

#!/bin/bash
# Let's check how the auto_focus setting is actually used in the form rendering
rg 'auto_focus' -A 5 -B 5 client/pages/forms/[slug]/index.vue

# Also check if there's any RTL-specific focus handling
rg 'rtl.*focus|focus.*rtl' client/

Length of output: 353


Script:

#!/bin/bash
# Let's examine the focusOnFirstFormElement function implementation
rg -A 10 'function focusOnFirstFormElement' client/pages/forms/[slug]/index.vue

# Also check for any RTL-related layout code
rg -A 3 'layout_rtl' client/

Length of output: 1848

api/app/Models/Forms/Form.php (1)

61-61: LGTM! The layout_rtl property is correctly added to fillable attributes.

The property is appropriately placed with other layout-related attributes in the customization section.

client/components/open/forms/OpenCompleteForm.vue (1)

Line range hint 150-157: Verify RTL text rendering in TextBlock component.

The TextBlock component will inherit RTL direction from its parent. Please ensure that:

  1. The submitted text renders correctly in RTL mode
  2. Mixed RTL/LTR content (if supported) displays properly
✅ Verification successful

RTL text rendering is properly handled by parent component

The TextBlock component inherits RTL/LTR direction correctly from its parent OpenCompleteForm.vue, which explicitly sets the direction based on the form's layout_rtl property:

<div :style="{ '--font-family': form.font_family, 'direction': form?.layout_rtl ? 'rtl' : 'ltr' }">

The TextBlock component is a simple wrapper that processes content through useParseMention and renders it with v-html, allowing it to naturally inherit the text direction from its parent container. No additional RTL-specific handling is needed in the TextBlock component itself.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if TextBlock component has any explicit direction styles that might conflict with RTL

# Test: Search for direction-related styles in TextBlock component
rg -t vue "direction|rtl|ltr" --glob "TextBlock.vue"

Length of output: 80


Script:

#!/bin/bash
# Search for TextBlock component file first
fd "TextBlock.vue"

# Then search for direction-related styles in the found files
rg "direction|rtl|ltr" $(fd "TextBlock.vue")

# Also check for any CSS classes that might affect text direction
rg "class=.*(?:direction|rtl|ltr)" $(fd "TextBlock.vue")

# Look for any v-bind directives that might set direction
rg ":style|:class" $(fd "TextBlock.vue")

Length of output: 313


Script:

#!/bin/bash
# Let's examine the TextBlock component content
cat client/components/forms/TextBlock.vue

# Also check parent component for any RTL-related styles or classes
cat client/components/open/forms/OpenCompleteForm.vue

Length of output: 11537

>
<img
alt="Logo Picture"
:src="form.logo_picture"
:class="{'top-5':!form.cover_picture, '-top-10':form.cover_picture}"
class="w-20 h-20 object-contain absolute left-5 transition-all"
class="w-20 h-20 object-contain absolute transition-all"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Logo positioning change needs to be reverted

The search results show that the logo positioning was previously handled with dynamic classes based on the cover picture presence:

:class="{'top-5':!form.cover_picture, '-top-10':form.cover_picture}"

This conditional positioning has been removed in favor of a static positioning, which will break the layout in different scenarios. The logo needs different vertical positions (top-5 vs -top-10) depending on whether a cover picture is present.

  • Revert the change and restore the conditional classes for proper logo positioning
  • Keep the other utility classes (w-20 h-20 object-contain absolute transition-all)
🔗 Analysis chain

Verify logo positioning in all scenarios.

The class binding has been simplified, but please verify that the logo positioning still works correctly in these scenarios:

  1. With cover picture
  2. Without cover picture
  3. With RTL mode enabled/disabled
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for related logo positioning styles and tests
echo "Searching for related logo positioning styles..."
rg -t vue "logo.*position|position.*logo" --glob "client/**/*.vue"

echo "Searching for related logo tests..."
rg -t js -t vue "logo.*test|test.*logo" --glob "client/**/*.{spec,test}.{js,ts,vue}"

Length of output: 399


Script:

#!/bin/bash
# Let's try a different approach to search for logo-related styles and layout
echo "Searching for logo-related styles in Vue files..."
rg "class=.*logo|class=.*w-20.*h-20" --type-add 'vue:*.vue' -t vue

echo -e "\nSearching for cover picture related code..."
rg "coverPicture|cover-picture" --type-add 'vue:*.vue' -t vue

echo -e "\nChecking RTL-related styles..."
rg "rtl|direction.*rtl|dir=.*rtl" --type-add 'vue:*.vue' -t vue

echo -e "\nLooking for the form component structure..."
rg -A 5 -B 5 "w-20.*h-20" --type-add 'vue:*.vue' -t vue

Length of output: 2656

@@ -58,6 +58,7 @@ class Form extends Model implements CachableAttributes
'border_radius',
'theme',
'width',
'layout_rtl',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Add boolean casting for the layout_rtl property.

For better data integrity and consistent type handling, consider adding the layout_rtl property to the casts array.

Add this to the casts array in the casts() method:

     protected function casts(): array
     {
         return [
             'properties' => 'array',
             'database_fields_update' => 'array',
             'closes_at' => 'datetime',
             'tags' => 'array',
             'removed_properties' => 'array',
-            'seo_meta' => 'object'
+            'seo_meta' => 'object',
+            'layout_rtl' => 'boolean'
         ];
     }

Committable suggestion skipped: line range outside the PR's diff.

@JhumanJ JhumanJ merged commit 62e980a into main Nov 20, 2024
5 checks passed
@JhumanJ JhumanJ deleted the 12fa6-right-to-left-mode branch November 20, 2024 14:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants